Support opt-in UIDONLY acquisition for large Yahoo mailboxes - #337

Why

Yahoo's large-mailbox export path caps the ordinary IMAP view and advertises RFC 9586 UIDONLY together with RFC 9394 PARTIAL and MESSAGELIMIT. Bichon needs an explicit, bounded UIDONLY path to archive the complete mailbox instead of silently accepting the capped view.

The feature is default-off per account so existing users and ordinary IMAP servers retain the current behavior until an administrator opts in.

Supersedes #334. Resolves #333.

Review by commit

This PR intentionally reaches the end state through three self-contained check-ins:

1. 8bda777 — bounded UIDONLY protocol guard and transcript tests
2. 9c69043 — canonical UID-scoped storage and projection primitives
3. d6efe7b — opt-in acquisition routing, checkpointing, ordinary-IMAP compatibility, and Web setting

Reviewing the commits in order separates the wire boundary, persistence boundary, and product integration while keeping one mergeable PR.

Resulting behavior

• Accounts remain on the existing IMAP path by default.
• Explicitly enabled accounts use UIDONLY only when the server advertises the exact UIDONLY + PARTIAL + MESSAGELIMIT capability set.
• Acquisition pages a fixed UID snapshot, preserves exact raw bytes, verifies canonical receipts, and advances the mailbox checkpoint only after successful projection.
• Ordinary IMAP retains upstream's UID-stable batching, maximum-message-size behavior, and empty-mailbox fast path.
• Automatic reconciliation with records from a previous capped Yahoo import is intentionally excluded.
• Disabling the setting takes effect at the next synchronization; mid-run revocation is not part of this change.

Risks when enabling for an existing mailbox

Enabling UIDONLY is a local archive migration decision, not merely a performance setting:

• Records previously imported through Yahoo's ordinary capped view retain their legacy identity. UIDONLY records use source-scoped UID identity, and this PR does not reconcile, replace, or delete the legacy records. Messages already present locally may therefore be downloaded again and appear as duplicate logical records or search results.
• The first UIDONLY run can traverse substantially more mail than the capped view exposed. Operators should expect a potentially large increase in download time, bandwidth, and local storage and should verify capacity first.
• A verified backup should be taken before enabling it on an existing archive. Disabling the setting later stops UIDONLY acquisition at the next synchronization; it does not convert or reconcile records already written. Likewise, downgrading to a Bichon version that predates these records should not be treated as a safe rollback procedure.
• Operators requiring a duplicate-free transition should wait for or perform an explicit reconciliation workflow; none is included here.
• These risks affect the local archive only. The UIDONLY path uses read-only IMAP commands and does not change remote messages, flags, or folders.

Verification

• cargo check --workspace
• Web production build
• 38 focused UIDONLY/acquisition/storage tests
• 18 ordinary-IMAP flow tests (4 credentialed tests ignored)
• empty-mailbox fast-path regression
• all 61 blob unit, durability, fuzz, and integration tests on the pre-rebase end state
• disposable Cyrus 3.12: two exact messages, restart with zero body refetch, cleanup verified
• bounded read-only Yahoo: one metadata-only connection plus one sample connection, at most 10 inventory records, one body capped at 25 MiB, no mutations